iT邦幫忙

2026 iThome 鐵人賽

DAY 8
0

Berry AI 的得來速計時系統,一間門市的車道上會裝 5 到 15 支 IP camera (後面簡稱 IP cam),Vision AI 判斷車輛的位置與動線,靠的全是它們拍回來的畫面。

這些相機由當地的施工廠商裝上、接進 PoE switch,我們的工程師遠在台灣。網段裡有幾支相機、各是什麼型號、串流要去哪裡拿,全都得由 edge server 自己問出來 (Day 04 提過這件事)。

那就寫個程式逐台問過去吧,聽起來不難。麻煩的是,該問什麼、怎麼問,得先看是哪一家的相機…

同樣是 RTSP,URL 每一家都自己訂

RTSP 是標準協定這點沒問題,但是串流的 URL 路徑長什麼樣子,完全由各家廠商自己決定,/Streaming/Channels/101/cam/realmonitor?channel=1&subtype=0 之類的寫法五花八門;想改解析度、想關掉自動對焦,更是各家有各家的 HTTP API 與參數名稱。每支援一個新品牌就寫一套 adapter,同品牌的型號不同還得再分一次,這樣下去工程師都不用做別的事了。

ONVIF 是什麼?

ONVIF 是監控設備廠商在 2008 年共同組成的組織,替網路攝影機、NVR 這類設備定義了一套通用介面 (縮寫原本代表 Open Network Video Interface Forum,後來標準的範圍不只影像,全名就停用了)。它用 WSDL 描述服務、以 SOAP over HTTP 交換訊息,都是那個年代的技術選擇,但也因為夠老,市面上絕大多數的 IP cam 都支援。

ONVIF 把功能切成幾個 profile,設備登錄成某個 profile 的符合產品 (conformant product),就代表它實作了對應的必要功能:

Profile 內容
S 基本的影像串流與設定;PTZ、音訊輸入、multicast 等是設備有支援才涵蓋的條件項
T S 的功能幾乎都有,再加上 H.265、影像參數、移動偵測與遮蔽破壞事件,認證也多了更安全的 digest
G 錄影與回放
M metadata 與事件分析

Profile S 正在淘汰,接手的是 Profile T,原因不在功能而在資安 — Profile S 規定一定要支援 WS-UsernameToken,以現在的標準來看已經不夠安全了。2027 年 3 月 31 日之後就不能再申請 Profile S 認證,不過已經裝在現場的設備照常運作,採購新機時確認有 Profile T 就好。

Edge server 怎麼問出串流位址?

edge server 先以 multicast 發出 Probe 找到網段內的相機,接著查詢設備資訊與能力,最後取得 RTSP 串流位址

三個步驟對任何廠牌都是同一套呼叫,差別只在回傳的內容;而每一步都得拿到上一步的回應才發得出去。

  1. 找出設備:ONVIF 的裝置發現走 WS-Discovery,往 multicast 位址 239.255.255.250:3702 送一個 Probe,網段內的相機就會各自回一個帶著服務位址的 ProbeMatch,事先不必知道任何一支相機的 IP。
  2. 問出能力:帶上帳號密碼呼叫 GetDeviceInformation 拿到型號、序號、韌體版本,再用 GetServices 問出這台相機提供哪些服務。序號尤其重要,Day 09 會用到它。
  3. 拿到串流GetProfiles 列出相機上設定好的媒體 profile (解析度、codec、bitrate 的組合),挑定一個之後用它的 token 呼叫 GetStreamUri,回傳的就是我們要的那條 RTSP 位址啦!

到這裡,edge server 已經可以在一間全新的門市裡,不靠任何人工整理的相機清單,自己把每一支相機的型號與串流位址問出來。

理論上就這樣,實際上沒這麼簡單

  • 問設備有哪些服務,早期用 GetCapabilities,官方 WSDL 已標明被 GetServices 取代,但舊設備只認得 GetCapabilities。建議先試 GetServices,不支援再改用舊的
  • GetStreamUri 回傳的位址不能照抄。有些相機填的是自己的內部 hostname,也可能是 DHCP 換發前的舊 IP。最保險的做法是只取路徑與 port,host 一律換成我們實際連上去的那個 IP
  • profile 請用 token 當 key,不要用 name。不同廠牌很常把 profile 都取名叫 mainstreamsubstream,名字撞在一起,內容卻完全是兩回事
  • WS-Discovery 走 UDP multicast,跨不過 VLAN 與大多數的三層設備。相機與 edge server 必須待在同一個廣播網域裡,這件事會反過來影響現場的網路規劃
  • 認證方式有 WS-UsernameToken 與 HTTP Digest 兩種,各家支援的程度不一。Profile S 時代的舊機型可能只吃前者,Profile T 的新機型則應該走後者,實作上兩種都得準備好
  • 「支援 ONVIF」與「完整實作 ONVIF」是兩件事。而且符合性是廠商自己拿 ONVIF 的測試工具跑完、提交聲明去登錄的,ONVIF 並不做第三方驗證。選配的功能,廠商不實作並不算違規,就算是必要功能,也還是遇得到回傳值怪異的相機。要導入新型號的時候,自己跑一輪相容性測試比讀規格書實在得多唷!

小結

不管網段裡裝的是哪一家的相機,問法都是同一套:找出設備、問出能力、要一條串流位址。不必逐台登入 Web UI,也不必為了新品牌從頭寫一次。

至於答案回來長什麼樣子,那就是另一回事了 — 上面那些坑就是這麼來的。

參考資料


本系列由 Berry AI 工程團隊出品。更多工程實戰紀錄都在 Berry AI 技術部落格


上一篇
影像串流一把罩,最強開源 Media Server — MediaMTX
下一篇
如何規模化取得每支相機的內部參數?單相機校準 (Single Camera Calibration) 產線 SOP
系列文
Berry AI:從零開始打造全美第一的得來速 Vision AI10
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言